The present invention relates generally to the management of data across domains, an in particular to using workflows to manage data across multiple systems and sources.
As an ever increasing number of services is being offered by various network providers, there is a corresponding increase in the number of systems, devices, applications, and components that utilize and store data for customers. Data typically is stored in databases as either structured or unstructured data. Directories (e.g., Lightweight Directory Access Protocol (LDAP) directories) can be used to store the data, as well as various schemas. For XML data, for example, the data can be stored in XML-aware databases, and repositories such as are found in XDM servers allow storage and exchange of XML data. All these are particular examples of data repositories.
Existing systems do not provide a view or aggregation of data from other domains, where data manipulation can be accomplished, accompanied by, or conditioned by execution of a policy (i.e., any combination of any condition and any action) that may call other systems to perform tasks that may update or result into updates of the data as needed, and that provide a view of the updated results or that may call other systems to perform tasks as a result of the update. Typically, these other systems are the “master controller” or “owner” of the data that is viewed. Data manipulation then is typically done as a request to change data in a system, a security check or identity authentication/validation, and a change of data by the database or repository. Such approaches can lead to problems in that changes made in one system might not align or be consistent with other systems using the same data, or consistent with related data in the same or other systems.
Certain information thus overlaps or is related to other information stored for different services or in different repositories. Unfortunately, it is not practical for most entities to rewrite the schemas or redesign all the systems and services to use a common data model, single repository, single point of access, etc. As such, there typically is no way to treat the various repositories as a single data source that is readily available to applications, users, etc.
A significant problem thus exists in the fact that updating information in one data repository may require corresponding changes or updates in other repositories, with each repository storing information for multiple applications. In order to update data in a repository, the overall system assumes that several applications may have been triggered by the result, or at an intermediate step, and that these applications have executed their own processes may have changed the context or data elsewhere. For example, adding a subscription for a user in a Business Support System (BSS) may also require updating support data and asset data (e.g. in an OSS, Network, or run time environment like SDP), as well as ensuring that some provisioning, activation, fulfillment, and/or billing takes place, etc. If the data is allowed to be updated without following all such flows, data existing elsewhere (e.g. catalog or provisioning flows, new rates, inventories of assets associated to a principal (e.g. subscriber) or support details, etc.) may be dropped (i.e., not appropriately added/updated). Further, other data in the same repository that might need to be modified as a result of the change might not be modified appropriately. For example, an action such as creating a customer record in a customer database for a business such as a telecommunications service provider requires other updates or processes to be run for other systems, such as where a new customer must be added to the billing system in order to ensure that the customer will be billed for the service. The customer information must also be added to a support system so that the customer can receive necessary support, etc. It thus is not enough to simply update the information locally, but all other necessary processes also must be executed in response to the update.
For example, a telecommunications service provider typically maintains a large set of different repositories that each contain certain information about customers of that provider. A number of systems and components may include Business Support Systems (BSS), a Service Delivery Platform (SDP), Operational Support Systems (OSS), and various other applications, third party content, and services. Each of these systems typically includes at least one repository containing a specific type of information, which generally is not substantially related or available to information in the repositories of the other systems.
For example, a BSS repository can store customer information from a service provider (business) point of view, such as customer address information, customer billing information, products purchased by the customer, and campaigns to which a customer has responded. A BSS repository also can include subscription information for a customer, such as information for any voice, wireless, data, or roaming plan, as well as number of minutes purchased per month, the terms of the plan, SLA etc. Such information is treated as product information from a BSS (e.g. CRM) point of view, and the BSS repository also will include information as to whether a particular customer is subscribing to that product. If, for example, a customer subscribing to a new subscription may entitled to a new phone or promotion or phone renewal terms or bundling, etc., that information typically will be maintained in the BSS repository. A BSS (e.g. CRM) repository also typically is used to maintain trouble tickets, such as information regarding problems with service or failure to receive a form, status of the ticket etc.
An OSS repository, on the other hand, can be used for monitoring and administration of the system. An OSS repository can contain subscriber information such as information for the current and active bill for a customer, an inventory of assets, provisioning and activation status (i.e., what is activated, what needs to be activated, etc., such as an order fulfillment status) associated with a customer, types of products or services provided to a customer, etc. A repository at the network level might include current network information for a customer, such as whether the customer is logged onto the network, a location of the customer on the network, whether a customer device is active, presence (one may argue if that is network or service level data, but it does not matter), etc. An application/service level repository (e.g., exposed within a service delivery platform (SDP)) stores subscription information for a customer that is useful in running software services that are exposed to the customer, such as whether a particular customer has requested to receive news updates, and if so, also stores preference information such as which types of news the customer wishes to receive, e.g., international news or news related to a specific topic, as well as a channel in which to receive the news (e.g., SMS or MMS) and format information for the news (e.g., background color and font size). The SDP repository also can include information such as an identity for each customer, customer availability, etc.
As can be seen, there is certain information that overlaps or is related to other information stored for different services or in different repositories. Unfortunately, it is not practical for most entities to rewrite the schemas or redesign all the systems and services to use a common data model, single repository, single point of access, etc. As such, there typically is no way to treat the various repositories as a single data source that is readily available to applications, users, etc.
In the case of a service, when an update is to take place it often is difficult to know where information is located, which information needed to be updated, as well as anything else that may need to be updated in order to maintain consistency of the entire system. This can significantly slow access, use, and changes to data such as subscription data. Many initiatives to offer such capabilities either fail or are extremely difficult to implement and/or integrate within a service provider's domain.
Further, a problem exists in the fact that updating information in one data repository may require corresponding changes or updates in other repositories. If a specific repository includes customer subscription information, there can be multiple applications that write that information in the repository, and update the repository, so that the repository reflects the subscriptions for all services. For a business such as a telecommunications service provider, however, an action such as creating a customer record in a customer database requires other updates or processes to be run for other systems. For example, a new customer must be added to the billing system in order to ensure that the customer will be billed for the service. The customer information must also be added to a support system so that the customer can receive necessary support, etc. It thus is not enough to simply update the information locally, but all other necessary processes also must be executed in response to the update.
Even after a customer record is created in all the appropriate systems, the customer may subscribe to different services or purchase different equipment, which can require updates in any appropriate system. Thus it would be desirable to have a way to ensure that all appropriate processes and updates are launched in response to an update in data of any system or repository across a domain.